/*
 * Alloy Analyzer
 * Copyright (c) 2002 Massachusetts Institute of Technology
 *
 * The Alloy Analyzer is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation; either version 2 of the License, or
 * (at your option) any later version.
 *
 * The Alloy Analyzer is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details.
 *
 * You should have received a copy of the GNU General Public License
 * along with the Alloy Analyzer; if not, write to the Free Software
 * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
 */

package alloy.ast;


/** an abstraction for the identifier of a leaf node in the
    AST.  LeafIds should be compared using the equals() method.

    Ilya Shlyakhter wrote:

    two leaves of the AST have the same LeafId iff they
represent the same thing, where "thing" can be:
relation, quantified variable, operator, univ/iden/none
of a given RelationType; anything else?  LeafIds allow
uniform treatment in some cases (e.g. template detection)
where all that matters is whether two leaves are the same
and it doesn't matter what kind of leaf they are.

because LeafIds identify relations (i.e. each relation
in the model has a unique LeafId), they're used whenever
we have a set of relations, or a map from relation to something.
(an alternative could be to identify relations by fully-qualified
 names).

also, because each quantified variable has a unique LeafId
(shared among all AST leaves that are instances of that quantified variable),
LeafIds are also used in places like DeclIter to refer to particular
quantified variables.  and they're used widely in alloy.transl.ASTInfo
to return various useful information about relations and quantified
variables.  again, LeafIds allow uniform treatment (e.g. what's the
RelationType of leaves with this LeafId?  as opposed to what's the
relation type of this relation, of this quantified variable etc).


    JE commentary:

    LeafId might better have been called SemanticAtom. Much semantic info is
    encoded as Maps on LeafId's, as in transl.ASTInfoVisitor,
    which is constructed by alloyRunner.translateCommand. It may help to think
    of this as a relational Alloy-style model, where the LeafId's are a single
    universal type with many sets and relations defined over it.
*/

public class LeafId implements Comparable {

    /** id for built-in Int type */
    /* NOTE:  (see doc/subtype-impl-notes, 06/26/03 entry for details)
     * Initializing INT_ID this way is necessary because calling
     * new LeafId will cause the next call to LeafId to return
     * the same integer as that assigned to INT_ID
     */
    //public static final LeafId INT_ID = new LeafId(0);

    //public static final LeafId EMPTY_ID = new LeafId(1);

    private static int _count = 0;

    private final Integer _id;

    private LeafId(int id_) {
        _id = new Integer(id_);
    }

    public LeafId() {
        this(_count++);
    }

    public boolean equals(Object obj) {
        if (! (obj instanceof LeafId)) return false;
        return _id.equals(((LeafId)obj)._id);
    }

    public int hashCode() {
        return _id.hashCode();
    }

    public int compareTo(Object obj_) {
        return _id.compareTo(((LeafId)obj_)._id);
    }

    public String toString() {
        return _id.toString();
    }
}

